Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-130.txt

Text File | 1994-12-08 | 46.8 KB | 1,317 lines | [TEXT/R*ch]

C.S.M.P. Digest             Fri, 03 Jul 92       Volume 1 : Issue 130

Today's Topics:

    Summary: Center Alerts?
    GWorlds and Off Screen Bitmaps....
    yacc for Think C 5.0?
    Proper way to copy file
    ?How to tell locked file?
    Troubles with TCL CStdPopupPane
    Postscript files - Printing -
    Info about AppMaker v1.2 and MacApp
    MPW C Error Funnies
    high-speed serial communications (again)



-------------------------------------------------------

From: [e-mail] (Jim Ryan)
Subject: Summary: Center Alerts?
Organization: Adobe Systems Incorporated
Date: Mon, 18 May 1992 20:57:09 GMT

Here's the C code snipet that I used to center alerts... it's not pretty,
but it works.  If anyone has any suggestions to better this code, please
let me know.  Thanks to all who pointed me in the right direction with
the excellent advice!

//--------------------------------------------------------------------------
void CenterAlert(int alertID)
{
    Rect     **theRectHandle;
    Rect     *theRectPointer;
    int     width, height;

    // get a handle
    if ((theRectHandle = (Rect **)GetResource('ALRT', alertID))) {

        // dereference handle
        HLock(theRectHandle);
        theRectPointer = *theRectHandle;
        HUnlock(theRectHandle);

        // get the alert's dimensions
        width = theRectPointer->right - theRectPointer->left;
        height = theRectPointer->bottom - theRectPointer->top;

        // change the alert's bounds in memory
        theRectPointer->top = 20 + gDragRect.top + ((gDragRect.bottom -
                                                    gDragRect.top) - height) / 3;
        theRectPointer->bottom = theRectPointer->top + height;
        theRectPointer->left = gDragRect.left + ((gDragRect.right -
                                                    gDragRect.left) - width) / 2;
        theRectPointer->right = theRectPointer->left + width;

        // let go of the sucker
        ReleaseResource(theRectHandle);
    }
}
//--------------------------------------------------------------------------

jr

+++++++++++++++++++++++++++

From: [e-mail] (Christophe Meessen)
Date: 19 May 92 08:14:01 GMT
Organization: Universite Catholique de Louvain (Belgium)

some comments:

In article <[e-mail]>, [e-mail] (Jim Ryan)
writes:
>
> Here's the C code snipet that I used to center alerts... it's not pretty,
> but it works.  If anyone has any suggestions to better this code, please
> let me know.  Thanks to all who pointed me in the right direction with
> the excellent advice!
>
> //--------------------------------------------------------------------------
> void CenterAlert(int alertID)
> {
>     Rect     **theRectHandle;
>     Rect     *theRectPointer;
>     int     width, height;
>
>     // get a handle
>     if ((theRectHandle = (Rect **)GetResource('ALRT', alertID))) {
>
>         // dereference handle
>         HLock(theRectHandle);

You don't realy need to lock the bloc because none of the following
instructions will move blocs in memory.

>         theRectPointer = *theRectHandle;
>         HUnlock(theRectHandle);

theRectPointer is a pointer on the bloc. Unlocking the bloc may change this
pointer into a dangling pointer. Unlocking should be done when the pointer
is no more used. BTW it isn't necessary in this code.

>
>         // get the alert's dimensions
>         width = theRectPointer->right - theRectPointer->left;
>         height = theRectPointer->bottom - theRectPointer->top;
>
>         // change the alert's bounds in memory
>         theRectPointer->top = 20 + gDragRect.top + ((gDragRect.bottom -
>                                                     gDragRect.top) - height) / 3;

gDragRect is a program global variable. To use this code, we must declare
this global and set it's value. What value ?
Better use the screenBits.bounds which is a system global variable. It will
give the same result and the user won't have to care about gDragRect.
Note1: 20 is the Menu_Bar_height
Note2: this alert is not verticaly centered.

               _______________________________________...s.top = 0
            |_____Menu____________________________|
            |                  .                  |
            |          _________________..........|...(s.bottom - height)/3
            |          |       .       |          |
            |..........|.......x.......|..........|...s.bottom / 3
            |          |       .       |          |
            |          |       .       |          |
            |          |       .<-1/2->|          |
            |          |_______________|          |
            |                  .                  |
            |                  .                  |
            |                  .<------1/2------->|
            |                  .                  |
            |                  .                  |
               |_____________________________________|...s.bottom


On all screens screenBits.bounds.top = screenBits.bounds.left = 0. We may
ignore the menu_bar_height in the positioning of the Alert. We can than
compute the Alert rect with the following functions:

theRectPointer->top = ( screenBits.bounds.bottom - height ) / 3;
theRectPointer->bottom = theRectPointer->top + height;
theRectPointer->left = ( screenBits.bounds.left - width ) / 2;
theRectPointer->right = theRectPointer->left + width;

>         theRectPointer->bottom = theRectPointer->top + height;
>         theRectPointer->left = gDragRect.left + ((gDragRect.right -
>                                                     gDragRect.left) - width) / 2;
>         theRectPointer->right = theRectPointer->left + width;
>
>         // let go of the sucker
>         ReleaseResource(theRectHandle);
>     }
> }
> //--------------------------------------------------------------------------
>
> jr


Chris

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 19 May 92 23:07:22 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Jim Ryan) writes:
>
> Here's the C code snipet that I used to center alerts... it's not pretty,
> but it works.  If anyone has any suggestions to better this code, please
> let me know.  Thanks to all who pointed me in the right direction with
> the excellent advice!
>
> ...
>
>         theRectPointer->top = 20 + gDragRect.top + ((gDragRect.bottom -
>                                                     gDragRect.top) - height) / 3;

Are you using 20 to take into account the height of the menubar? If so, call
GetMBarHeight() instead.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Peter N Lewis)
Organization: NCRPDA, Curtin University
Date: Thu, 21 May 1992 01:27:09 GMT

In article <[e-mail]>, [e-mail] (Jim Ryan) writes:

> //--------------------------------------------------------------------------
> void CenterAlert(int alertID)
> {
>     Rect     **theRectHandle;
>     Rect     *theRectPointer;
>     int     width, height;
>
>     // get a handle
>     if ((theRectHandle = (Rect **)GetResource('ALRT', alertID))) {
>
>         // dereference handle
>         HLock(theRectHandle);
>         theRectPointer = *theRectHandle;
>         HUnlock(theRectHandle);
>
>         // get the alert's dimensions
>         width = theRectPointer->right - theRectPointer->left;
>         height = theRectPointer->bottom - theRectPointer->top;
>
>         // change the alert's bounds in memory
>         theRectPointer->top = 20 + gDragRect.top + ((gDragRect.bottom -
>                                                     gDragRect.top) - height) / 3;
>         theRectPointer->bottom = theRectPointer->top + height;
>         theRectPointer->left = gDragRect.left + ((gDragRect.right -
>                                                     gDragRect.left) - width) / 2;
>         theRectPointer->right = theRectPointer->left + width;
>
>         // let go of the sucker
>         ReleaseResource(theRectHandle);
>     }
> }

Two comments on this code.  First, when you dereference a handle like that,
you need to keep it locked for as long as you have the dereferenced
value stored in a local variable.  So the HUnlock should be just before
the ReleaseResource.

Second (and totally the opposite :), you don't need to lock the handle
unless you are going to call a procedure that can move memory.  A safe
bet is to assume that any toolbox call except BlockMove and FSRead/Write
(perhaps someone could give a list of all calls which Apple guarentees
will never move memory, since the list of traps which can is ever growing).
Also note that any procedure call you make to a different segment may
move memory - this is particularly important if you use objects which
are implemented as handles....  Anyway, a very safe assumption is that
straight arithmetic stuff like you have in the above code will not move
memory, so the HLock and HUnlock is redundant, but if you really want
to use it, put the HUnlock at the bottom just before the ReleaseResource.

A third comment is on the validity of that code - if you release the
resource surely the handle will (or could?) be disposed and all your
work will be wasted... shouldn't you wait til after the Alert call
before you release it?

Have fun all,
   Peter.

______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University      [e-mail]
GPO Box U1987, Perth WA 6001, AUSTRALIA            FAX: [phone]



+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 19 May 92 17:20:14 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Jim Ryan) writes:
>Here's the C code snipet that I used to center alerts... it's not pretty,
>but it works.  If anyone has any suggestions to better this code, please
>let me know.  Thanks to all who pointed me in the right direction with
>the excellent advice!

>        // let go of the sucker
>        ReleaseResource(theRectHandle);
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This code actually works? It was my understanding to read in the alert
data into a handle, adjust the rect coordinates and then call alert.
The alert call will then deal with the preloaded resources.




Matt

- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Jim Ryan)
Organization: Adobe Systems Incorporated
Date: Wed, 27 May 1992 00:04:25 GMT

> >        // let go of the sucker
> >        ReleaseResource(theRectHandle);
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This code actually works? It was my understanding to read in the alert
> data into a handle, adjust the rect coordinates and then call alert.
> The alert call will then deal with the preloaded resources.
>
> Matt
>

Unbelievable as it may appear, it works... I found that if I didn't let go,
then all hell would break loose if the alert was immediately called again...
like it would not show up the second call, it would be 20x20000 the next , the
 next time it wouldn't appear, etc, etc.  How, why, I have no idea...

jr

+++++++++++++++++++++++++++

From: [e-mail] (Jim Ryan)
Organization: Adobe Systems Incorporated
Date: Wed, 27 May 1992 20:47:08 GMT

I lied.... I was fooled by the ResEdit feature that centers windows
under System 7.  Matt is correct, releasing the resource will cause the
alert to NOT
be centered.  My problem with calling the alert multiple times seems
to have vanished, as it appears to work now.  Hmmm.  Thanks to Matt
for pointing the problem out!

jr

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Thu, 28 May 1992 10:32:13 GMT

> [e-mail] (Jim Ryan) writes:

   under System 7.  Matt is correct, releasing the resource will cause the
   alert to NOT
   be centered.  My problem with calling the alert multiple times seems
   to have vanished, as it appears to work now.  Hmmm.  Thanks to Matt


However, I still have, and have had for some time, the same
problem with GetResource - set rectangle - Alert failing
and giving me strange alert rects outside the screen. This
is using the Think Class Library code... so I scrapped that
and only use System 7 auto-position (we are system 7
dependant anyway)

- --
h++ - new and improved !

A Bus Station is where buses stop. A Train Station is where
trains stop. On my desk, there is a Work Station.

+++++++++++++++++++++++++++

From: [e-mail]  (Christophe Meessen)
Organization: Universite Catholique de Louvain (Belgium)
Date: Tue, 2 Jun 1992 13:42:19 GMT

I submit here the source code as I tested it. It's a compilation of all
remarks.

I tested it on a Classic OS 7.0, Mac Plus OS 6.5 with an A4 Radius screen
and a SE30 OS 6.5 with the Apple 21' b&w screen.

It is OS 7.0 independent !



//--------------------------------------------------------------------------
 void CenteredAlert(int alertID)
 {
       Rect     **theRectHandle;
       Rect     *theRectPointer;
       int     width, height;

       // get a handle
       if ((theRectHandle = (Rect **)GetResource('ALRT', alertID))) {

             // dereference handle
             theRectPointer = *theRectHandle;

             // get the alert's dimensions
             width = theRectPointer->right - theRectPointer->left;
             height = theRectPointer->bottom - theRectPointer->top;

             // change the alert's bounds in memory
             theRectPointer->top = ( GetMBarHeight() +
qd.screenBits.bounds.bottom -
                                                                  height) /
3;
             theRectPointer->bottom = theRectPointer->top + height;
             theRectPointer->left = (qd.screenBits.bounds.right - width) / 2;
             theRectPointer->right = theRectPointer->left + width;

             // show the alert
             Alert( alertID,NULL );

             // let go of the sucker
             ReleaseResource(theRectHandle);
          }
 }

main(){

   InitGraf((Ptr) &qd.thePort);
   InitFonts();
   InitWindows();
   InitMenus();
   TEInit();
   InitDialogs(nil);
   InitCursor();

   CenteredAlert    ( 128 );
}

Bien cordialement,

                           Christophe MEESSEN

---------------------------

From: [e-mail] (Danny McCampbell)
Subject: GWorlds and Off Screen Bitmaps....
Organization: University of Tennessee
Date: Wed, 27 May 1992 19:25:45 GMT

Could someone please give me a piece of Code that will let me create and
use offscreen GWorlds.

I cannot to save my life get Tech Note 120's code to work.

All I want to do is copy a color picture to the GWorld and back on
screen to get rid of the flicker.

Thanks.

Danny

+++++++++++++++++++++++++++

From: [e-mail] (Geoffrey Parsons, WKU)
Date: 1 Jun 92 16:23:39 GMT
Organization: Western Kentucky University, Bowling Green, KY

In article <[e-mail]>, [e-mail] (Danny McCampbell) writes:
> Could someone please give me a piece of Code that will let me create and
> use offscreen GWorlds.
>
> I cannot to save my life get Tech Note 120's code to work.
>
> All I want to do is copy a color picture to the GWorld and back on
> screen to get rid of the flicker.
>

  If you are using system 7 (and don't need sys6 support) then I would
suggest looking it to the GWorld (NewGWorld) routines in IM6. I too have
messed around with the technote crap to no avail. These routines seem to
work fine for me.

Cheers,
Geoffrey Parsons

+++++++++++++++++++++++++++

From: [e-mail] (Bill Leue)
Date: 2 Jun 92 12:49:27 GMT
Organization: General Electric Research & Development

Also, Scott Knaster and Keith Rollins's new Book, "Macintosh Programming
Secrets, 2nd Edition" has some nice code showing how to use GWorlds for
various jobs, including saving parts of the screen underneath dialogs
and the like for faster screen repair.

- -Bill Leue
[e-mail]

Disclaimer:  No, Keith's NOT giving me a commission for plugs - I just like
the book!

+++++++++++++++++++++++++++

From: Sherman@128.147.155.27 (Sherman Uitzetter)
Date: 2 Jun 92 14:29:27 GMT
Organization: NMRI Pittsburgh



     The GWorld routines in IM6 will work with system 6.0.7 and greater.


- -Sherman.

---------------------------

From: [e-mail] (Mario Garcia)
Subject: yacc for Think C 5.0?
Date: 27 May 92 21:57:13 GMT
Organization: The University of Texas at Austin, Austin TX

Hello again,

After reading Kernighan & Pike's excellent discussion of yacc (_The UNIX
Programming Environment_, chapter 8) and trying out a few things on the
unix machine, I thought it would be really neat to have something similar
to work on my mac.  I tried Bison but the code it generates is not compatible
with Think-C 5.0, and I don't haveW.  Is there a stand-alone yacc derivative
that generates ANSI compatible code?  Thanks for any leads on this.

- -------------------------------------------------------------------------------
Mario L. Garcia                                     1212 Guadalupe Apt. 802
Mathematics Student                                 Austin, TX 78701
The University of Texas at Austin                   [phone]
e-mail [e-mail]
- -------------------------------------------------------------------------------


+++++++++++++++++++++++++++

From: mike@uunet!tellab5!odgate (Mike J. Kelly)
Organization: Odesta Corporation
Date: Fri, 29 May 1992 20:21:31 GMT

[e-mail] (Mario Garcia) writes:

>Hello again,

>After reading Kernighan & Pike's excellent discussion of yacc (_The UNIX
>Programming Environment_, chapter 8) and trying out a few things on the
>unix machine, I thought it would be really neat to have something similar
>to work on my mac.  I tried Bison but the code it generates is not compatible
>with Think-C 5.0, and I don't haveW.  Is there a stand-alone yacc derivative
>that generates ANSI compatible code?  Thanks for any leads on this.

>-------------------------------------------------------------------------------
>Mario L. Garcia                                     1212 Guadalupe Apt. 802
>Mathematics Student                                 Austin, TX 78701
>The University of Texas at Austin                   [phone]
>e-mail [e-mail]
>-------------------------------------------------------------------------------

There is an MPW tool called MacYACC available from Abraxas Software in
Portland.  The code it generates should be compatible with Think C; we
compile it in Think C after massaging it a bit with a MPW script to make
it comply with some internal coding issues not relevant here.

Abraxas Software, 1-800-347-5214 or 503-244-5253.
- --
- --
Mike Kelly               Odesta Corporation, Northbrook, Illinois, USA
...!clout!odgate!mike    - Until odesta.com is registered.
odgate![e-mail]   - From the Internet.

+++++++++++++++++++++++++++

From: [e-mail] (Dan Eldred)
Date: 3 Jun 92 02:10:17 GMT
Organization: Jet Propulsion Laboratory

In article <1992May29.202131.8873@uunet!tellab5!odgate> mike@uunet!tellab5!odgate (Mike J. Kelly) writes:
>[e-mail] (Mario Garcia) writes:
>
>>Hello again,
>
>>After reading Kernighan & Pike's excellent discussion of yacc (_The UNIX
>>Programming Environment_, chapter 8) and trying out a few things on the
>>unix machine, I thought it would be really neat to have something similar
>>to work on my mac.  I tried Bison but the code it generates is not compatible
>>with Think-C 5.0, and I don't haveW.  Is there a stand-alone yacc derivative
>>that generates ANSI compatible code?  Thanks for any leads on this.
>
I've been using Bison with Think C 4.0 and I have successfully compiled
a number of smallish examples, as well as a huge language grammer (it
compiles the gram.y file but the code's still being worked on).  Haven't
tried Bison with Think C 5.0 yet but I doubt there will be any problems,
except perhaps that some of the checking (e.g. prototypes) may have to
be relaxed.

Included is other response:
>
>There is an MPW tool called MacYACC available from Abraxas Software in
>Portland.  The code it generates should be compatible with Think C; we
>compile it in Think C after massaging it a bit with a MPW script to make
>it comply with some internal coding issues not relevant here.
>
>Abraxas Software, 1-800-347-5214 or 503-244-5253.
>--
>--

- --Dan Eldred, [e-mail]

---------------------------

Subject: Proper way to copy file
From: [e-mail]
Date: 28 May 92 01:01:51 CST
Organization: University of Kansas Academic Computing Serces


What is the proper way to go about copying a file.  I have a
file reference number and know how to go about getting
a path name but am unsure how to procede.  I tried using
PBHFileCopy but can't seem to get the field of the
paramaBlockRec filled in correctly (error -50).  I bit of
help would be much appreciated.

For the purposes of having it in the archives in a month
or so, I will post my results.

Thanks.

+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 2 Jun 92 21:17:08 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] writes:

>What is the proper way to go about copying a file.  I have a
>file reference number and know how to go about getting
>a path name but am unsure how to procede.  I tried using
>PBHFileCopy but can't seem to get the field of the
>paramaBlockRec filled in correctly (error -50).  I bit of
>help would be much appreciated.

That call is only support on a few volumes like appleshare servers.
You need to check the volume to see if it supports that call.
Other wise you have to do the copy yourself.

If you didn't already get an answer to this question , email me and I'll
send you some code that does what you want. Since this question was
asked a little while ago (by myself I think) I don't want to post
the answer again.

Matt


- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

---------------------------

From: [e-mail] (Chuck McMath)
Subject: ?How to tell locked file?
Date: 28 May 92 13:30:21 GMT
Organization: MSD

I have a simple problem:

How do I tell if the file I'm opening is a locked file?  The definition
of locked could fall under a number of different cases: the file could
be on a locked volume (CD-ROM or locked floppy), it could be locked via
that little checkboxie in the Finder, or it could be on an AppleShare
volume that doesn't give me write access (is this the same as case 1?).

In any event, I need to determine if the file is un-updatable.  The only
way I can determine to do this is to check both the volume and the
file separately to see if they are locked.  Is there a better way?

chuck

(                       --chuck mcmath-
                    [e-mail]
  MSD, Inc. * National Library of Medicine * National Institutes of Health
                       Bethesda, MD 20894

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 28 May 92 23:57:34 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Chuck McMath) writes:
>
> I have a simple problem:
>
> How do I tell if the file I'm opening is a locked file?  The definition
> of locked could fall under a number of different cases: the file could
> be on a locked volume (CD-ROM or locked floppy), it could be locked via
> that little checkboxie in the Finder, or it could be on an AppleShare
> volume that doesn't give me write access (is this the same as case 1?).
>
> In any event, I need to determine if the file is un-updatable.  The only
> way I can determine to do this is to check both the volume and the
> file separately to see if they are locked.  Is there a better way?


I think the best way to determine if a file is "writable" is to open
the file and then set the EOF to the current EOF.

The problem really is that you can never tell if the state of writability
has changed since the last time you checked.  So, my advice is to just
check by always handling errors returned by the File System.  You may
want to check once up front telling the user that the file cannot be
modified by getting the current EOF and then attempting to set it to
the same EOF mark.  But if the permission status of the file has changed
after then check, you may get errors when you attempt to update the file
later.


- -----------------------------------------------------------------------
Jim Reekes, Polterzeitgeist  |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

From: [e-mail] (Brodie Lockard)
Date: 3 Jun 92 06:43:38 GMT
Organization: Academic Information Resources

In article <[e-mail]> [e-mail] (Chuck McMath) writes:

>How do I tell if the file I'm opening is a locked file?

I do a GetFInfo followed by a SetFInfo.

Brodie Lockard      [e-mail]

---------------------------

From: [e-mail] (Gregory M Ferrar)
Subject: Troubles with TCL CStdPopupPane
Organization: Department of Mathematics, The Ohio State University
Date: Fri, 29 May 1992 21:53:39 GMT

I'm trying to write a program using Think C 5.0, TCL 1.1.2, using popup menus.
I'm using a Quadra 700, running System 7.0.1 with TuneUp 1.0.  When a new
document is created, I set up the window and install the popup menu as follows:

   /* Create the problem subtype popup menu pane */
   subtype_menu_pane = new (CStdPopupPane);
   subtype_menu_pane->IStdPopupPane(133, the_window, document,
                                     kAutoSize, kAutoSize, 37, 22);

The popup menu is stored in MENU resource #133.  This works fine.  But if I
change the 133 above to 134, and change the MENU id to 134, it fails.  It
correctly draws and pops up the menu, but it doesn't update the menu to the
new selection, as it does when the MENU id is 133.

The only IDs which seem to work are 128, 129, 131, and 133 (though I can't say
I've tried all 65536 of them).

Any ideas why this isn't working?  There's nothing strange about the menu, and
changing the menu doesn't help.  If I put two popups in the window, one with
ID 133 and the other 134, the 133 works but the 134 doesn't.

  -Greg Ferrar ([e-mail])


+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 1 Jun 92 00:27:47 GMT
Organization: Taligent

In article <[e-mail]>,
[e-mail] (Gregory M Ferrar) writes:
>
> I'm trying to write a program using Think C 5.0, TCL 1.1.2, using popup menus.
> I'm using a Quadra 700, running System 7.0.1 with TuneUp 1.0.  When a new
> document is created, I set up the window and install the popup menu as
follows:
>
>    /* Create the problem subtype popup menu pane */
>    subtype_menu_pane = new (CStdPopupPane);
>    subtype_menu_pane->IStdPopupPane(133, the_window, document,
>                                      kAutoSize, kAutoSize, 37, 22);
>
> The popup menu is stored in MENU resource #133.  This works fine.  But if I
> change the 133 above to 134, and change the MENU id to 134, it fails.  It
> correctly draws and pops up the menu, but it doesn't update the menu to the
> new selection, as it does when the MENU id is 133.
>
> The only IDs which seem to work are 128, 129, 131, and 133 (though I can't say
> I've tried all 65536 of them).
>
> Any ideas why this isn't working?  There's nothing strange about the menu, and
> changing the menu doesn't help.  If I put two popups in the window, one with
> ID 133 and the other 134, the 133 works but the 134 doesn't.


Make sure that _both_ the MENU ID and the resource ID of your MENU resource are
134. TCL assumes that both numbers are the same, as does the popupmenu CDEF in
System 7.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


---------------------------

From: [e-mail] (Justin Harvey)
Subject: Postscript files - Printing -
Organization: Weber State University, Ogden Utah
Date: Fri, 29 May 92 23:04:53 GMT

I'd like to know if anyone can tell me how to print postscript files
on a Macintosh connected to a Laserwriter?

+-----------------------------------------+
|             Justin Harvey               |
- -------------------------------------------
|          6734-a Marguerite St.          |
|            Juneau, AK 99801             |
| [e-mail]  &  |
| [e-mail]  (News account) |
|          University of Alaska           |
+-----------------------------------------+

+++++++++++++++++++++++++++

From: [e-mail] (brett lindenbach)
Date: 31 May 92 15:18:00 GMT
Organization: microbiology, univ. illinois

In article <[e-mail]>, [e-mail] (Justin Harvey) writes:
>
> I'd like to know if anyone can tell me how to print postscript files
> on a Macintosh connected to a Laserwriter?
>
Indeed, I do (one of the few questions on this group I can answer). There
exists a utility from Apple called Laserwriter Utility. It should be found
on the ftp site: ftp.apple.com login:anon. pswd:e-address. This application
permits one to dump directly to the printer. However, it only works for Apple
printers. I have an hp laserjet ///, and here's what I do:
     - load document into MSWord
     - select whole document (option-command-m)
     - pull-down FORMAT menu to "Define All Styles"
       (this appears only if you select it with "Commands...")
     - select the postscript style, and APPLY to document
     - print
Best o'luck... BDL

+++++++++++++++++++++++++++

From: [e-mail] (Roy Richter PH/32)
Date: 1 Jun 92 15:26:31 GMT
Organization: GM Research, Warren, Mi

|> In article <[e-mail]>, [e-mail] (Justin Harvey) writes:
|> >
|> > I'd like to know if anyone can tell me how to print postscript files
|> > on a Macintosh connected to a Laserwriter?
|> >

I'd like to do this from within my program.  Having read Inside Macintosh
(that model of exposition and clarity, if not usefulness) I gather I need
to do some down-and-dirty printer driver stuff.  I was hoping more for
a "transparent" mode I could put the Print Manager into.  I'm doing
simple stuff, like trying to put an RGB or CYMK bitmap out to a
PostScript printer.  I've already done the RIP-ing, and I find if I go
through QuickDraw I need to wait for another conversion to PostScript.
Also, many of thes items are native CYMK images, so it would save those
conversions to RGB, too.

Any Help?  Pointer to "this is the classic Tech Note" or book?
- --
Roy Richter                  Internet: [e-mail]
Physics Dept, GM Research    UUCP:     rphroy!rrichter

+++++++++++++++++++++++++++

From: [e-mail] (Charles B. Cranston)
Organization: UM Home for the Terminally Analytical
Date: Mon, 1 Jun 1992 15:58:36 GMT

In article <[e-mail]>, [e-mail] (Justin Harvey) writes:

> I'd like to know if anyone can tell me how to print postscript files
> on a Macintosh connected to a Laserwriter?

Adobe provided a program called SendPS that (among other functions) downloaded
an arbitrary text file via AppleTalk to LaserWriters.  It was at level 2.0 last
time I saw.  Amanda Walker wrote an MPW Tool called SendPS that did the same
thing (but since it was a tool you could redirect the diagnostic output to a
file or window a la Unix etc).

Both of these programs suffered in the System 7 conversion because they fetch
the PAP (Printer Access Protocol) routines from the LaserWriter file, which is
no longer in the System Folder where they are looking.  If you move LaserWriter
from Extensions (or wherever it lives now) back to the root System Folder they
start working again.  Updated versions would be much appreciated.

If you really want to write it yourself I suggest you use this PAP manager
interface.  You will find info on it in Best of Mactutor Volume II pages 97
and 179...


+++++++++++++++++++++++++++

From: [e-mail] (Matt Mora)
Date: 2 Jun 92 21:32:40 GMT
Organization: SRI International, Menlo Park, California

In article <[e-mail]> [e-mail] (Charles B. Cranston) writes:

>If you really want to write it yourself I suggest you use this PAP manager
>interface.  You will find info on it in Best of Mactutor Volume II pages 97
>and 179...

How does MS word do it then? Can't you just open/create a picture
stuff in all postscript using piccomments and then print the pict
to the printer? Or does this only work for one page?

Matt



- --
___________________________________________________________
Matthew Mora                |   my Mac  [e-mail]
SRI International           |  my unix  [e-mail]
___________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Dana S Emery)
Date: 3 Jun 92 05:52:27 GMT
Organization: Personal

In article <[e-mail]>, [e-mail] (Matt Mora) writes:

> How does MS word do it then? Can't you just open/create a picture
> stuff in all postscript using piccomments and then print the pict
> to the printer?

> Or does this only work for one page?

You got it, pic per page.  Also, your PS had better be handling both its own
Mac-encoding and font downloading, as support of the picts' postscript is NOT
automatic, so the App must parse the PS for font utilization and actually
print some real character (not a space, overly clever LW driver optimizes
lone spaces out) somewhere that won't image (?what to do for wall-wall
printers?, how about thumbnails?).

Ben and I have thrashed this out, doing a printer driver substitute  is
really the best way.  It should also be a lot faster, as the LW driver does
a lot of armwaving to pipe that PS out the port.

---------------------------

From: [e-mail] (T.J. Fiske)
Subject: Info about AppMaker v1.2 and MacApp
Date: 29 May 92 23:25:34 GMT
Organization: Qualcomm, Inc., San Diego, CA

I just read in the latest version of the APDA catalog of a
program called AppMaker v1.2 that is a prototyping tool that
will allow you to prototype in THINK Class Library and also
in MacAPP.  Does any one know if this means that you could
load up code from THINK Class Library, then convert it to work
with MacAPP.

I have code that is in the Think Class Library, that I desperately
need in a MacApp Format.  If anyone has an alternate solution, I'd
love to hear it.

Thanks,

    -- T.J. Fiske

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 31 May 92 22:33:50 GMT
Organization: MacDTS Mongols

In article <tfiske.707181934@qualcom>, [e-mail] (T.J. Fiske)
writes:
>
> I just read in the latest version of the APDA catalog of a
> program called AppMaker v1.2 that is a prototyping tool that
> will allow you to prototype in THINK Class Library and also
> in MacAPP.  Does any one know if this means that you could
> load up code from THINK Class Library, then convert it to work
> with MacAPP.
>
> I have code that is in the Think Class Library, that I desperately
> need in a MacApp Format.  If anyone has an alternate solution, I'd
> love to hear it.

You could load in general resources, but I don't personally see
any way to load real TCL code, and AppMaker automagically converts
it to MacApp 3.0 code. However if you use AppMaker as the generator
for interfaces, you could create either TCL or MacApp code, depending
on the phase of the moon, the political climate at the office, or
due to whatever legal, inofficial or official reason.
- --
                                              Cheers, Kent



---------------------------

From: [e-mail] (Paul Frederick Snively)
Subject: MPW C Error Funnies
Date: Sun, 31 May 92 15:48:17 PDT
Organization: The Portal System (TM)

My personal favorite:

`You can't: change the type of a constant, win an argument with the IRS, or
satisfy this compiler.'

Paul Snively

+++++++++++++++++++++++++++

From: [e-mail] (mark salter)
Date: 1 Jun 92 17:39:40 GMT
Organization: imagen

[e-mail] (Paul Frederick Snively) writes:

>My personal favorite:

>`You can't: change the type of a constant, win an argument with the IRS, or
>satisfy this compiler.'

>Paul Snively


Try this:

extern void void_proc(void);

main()
{
    (void) void_proc();
}


Results in this message:
Error 245 Can't cast a void type to type void (because the ANSI spec. says so, thats why)

Only thing is, I can't find a prohibition of this anywhere and every other ANSI
compiler on every other platform I've tried compiles this just fine.

Mark Salter

+++++++++++++++++++++++++++

From: [e-mail] (John F. Woods)
Date: 1 Jun 92 18:00:55 EDT

[e-mail] (mark salter) writes:
>[e-mail] (Paul Frederick Snively) writes:
>Try this:
>extern void void_proc(void);
>main()
>{
>    (void) void_proc();
>}
>Results in this message:
>Error 245 Can't cast a void type to type void (because the ANSI spec. says so, thats why)

>Only thing is, I can't find a prohibition of this anywhere and every other
>ANSI compiler on every other platform I've tried compiles this just fine.

There's a reason for that.            (_italics_ *bold*)

"3.2.2.2 void
   The (nonexistant) value of a _void_expression_ (an expression that has type
*void*) shall not be used in any way, and implicit or explicit conversions
(except to *void*) shall not be applied to such an expression."

Note that a void expression MAY be cast (converted) to void.  MPW C is in for a
spanking.


---------------------------

From: [e-mail] (Peter Creath)
Subject: high-speed serial communications (again)
Date: Fri, 29 May 92 22:29:34 CDT
Organization: Cube Technologies

A while ago I said Apple oughtta come out with some universal way
to allow the Mac to handle 115.2k serial port speeds.

Somebody mentioned that this wasn't possible in a standard sense because
(if I understand it correctly) AppleTalk gets its 200k speed by using
multiple channels, rather than one 200k data channel.

However, MacLink Plus connects to an IBM at 115.2k.  That would mean
that it is actually getting the serial port to go 115.2k.  I've worked
with IBM's and there's no way you can get the UART to blast out or
receive more than one data channel, so it's GOTTA be going down one
channel.

In summary, how the hell did they do that?

Can Apple come out with a update to the Comm Toolbox or a Snippet
so all the programmers out there can write a safe high-speed serial
app?

- ----------------------------------------------------------------------------
Peter Creath                 "When I was a boy I was told that anybody could
[e-mail]   become president; I'm beginning to believe it."
                                                           -- Clarence Darrow

+++++++++++++++++++++++++++

From: [e-mail]
Organization: Campus Computing Sites, University of Michigan-Ann Arbor
Date: Sun, 31 May 92 04:24:59 GMT

In article <[e-mail]> [e-mail] (Peter Creath)  writes:
>However, MacLink Plus connects to an IBM at 115.2k.  That would mean
>that it is actually getting the serial port to go 115.2k.  I've worked
>with IBM's and there's no way you can get the UART to blast out or
>receive more than one data channel, so it's GOTTA be going down one
>channel.
>
>In summary, how the hell did they do that?
>
    You may have noticed that MacLink comes with a special cable along
with a "black box" which attaches to the cable for those "high speed transfers".
That "black box" provides an external clock to the SCC, like the wires in
the LocalTalk boxes.  that is the ONLY way to get above 57.6Kb with the Mac's
current SCC & serial driver - external clocking!

>Can Apple come out with a update to the Comm Toolbox or a Snippet
>so all the programmers out there can write a safe high-speed serial
>app?
>
    Apple needs to do some more work on interrupt handling when AppleTalk
is in use first, then some work on making the serial driver a bit more robust
and THEN maybe we could at least do 57.6Kb.


- --
- -----------------------------------------------------------------------
Leonard Rosenthol          Internet: [e-mail]
Director of Advanced Technology   AppleLink: MACgician
Aladdin Systems, inc.          GEnie:     MACgician

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 31 May 92 22:45:39 GMT
Organization: MacDTS Mongols

In article <[e-mail]>,
[e-mail] writes:
> In article <[e-mail]> > >Can Apple come out with a
update to the Comm Toolbox or a Snippet
> >so all the programmers out there can write a safe high-speed serial
> >app?
> >
>     Apple needs to do some more work on interrupt handling when AppleTalk
> is in use first, then some work on making the serial driver a bit more robust
> and THEN maybe we could at least do 57.6Kb.

True, the problem really has to do with interrupt level handling, and not
enough cycles for successfully handling huge speeds, unless you either
have an external clock, a special hard and ICs with buffering, or many
other similar *outside* solutions. The trick is to raise the overall
level of the standard hardware, and trust me, this is a serious problem
we are trying to resolve due to the higher and higher speeds end users
will use with communication services.
- --
                                              Cheers, Kent



+++++++++++++++++++++++++++

From: [e-mail] (Jack Brindle)
Date: 1 Jun 92 03:37:55 GMT
Organization: Motorola, Mobile Data Division - Seattle, WA

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]> [e-mail] (Peter Creath)  writes:
>>However, MacLink Plus connects to an IBM at 115.2k.  That would mean
>>that it is actually getting the serial port to go 115.2k.  I've worked
>>with IBM's and there's no way you can get the UART to blast out or
>>receive more than one data channel, so it's GOTTA be going down one
>>channel.
>>
>>In summary, how the hell did they do that?
>>
>    You may have noticed that MacLink comes with a special cable along
>with a "black box" which attaches to the cable for those "high speed transfers".
>That "black box" provides an external clock to the SCC, like the wires in
>the LocalTalk boxes.

Leonard! Of all people, you should know better than this! First, the
LocalTalk boxes do not supply clock. LocalTalk uses the SCC's DPLL to
decode the clock from the transmitted FM0 coded data string. It also
generates it on transmit. This is easy since LocalTalk is not full duplex,
and the clock generator can be reprogrammed for the needed clock rates
for both tx and rx.

>                     that is the ONLY way to get above 57.6Kb with the Mac's
>current SCC & serial driver - external clocking!

This is true. The current asynchronous mode SCC driver cannot go above
57.6Kb. The SCC certainly can go above it, most notably in synchronous
mode (LocalTalk is but one example of this). The SCC does need help to
go faster in asynchronous mode. Obviously, though it is doable.

>>Can Apple come out with a update to the Comm Toolbox or a Snippet
>>so all the programmers out there can write a safe high-speed serial
>>app?
>>
>    Apple needs to do some more work on interrupt handling when AppleTalk
>is in use first, then some work on making the serial driver a bit more robust
>and THEN maybe we could at least do 57.6Kb.

This is not the only problem. (soapbox time...) The only mechanism that
Apple has given us for controlling the use of serial ports is through
the Communications Resource Manager of the CTB. Unfortunately, this
does not manage the hardware at all. It only manages software drivers.
So, if I install a synchronous driver using the modem port (port A),
the user can actually open a comm program and load an async driver for
the same port, reconfiguring the very hardware my driver is using. Note,
management at this level used to be in the Mac. Unfortunately, it appears
to have been removed, and in any rate, Apple told us not to use it. I
actually have gone to opening the async driver for the port I want to
use, then stealing the hardware out from under it. Calls to the "open
driver" routine will return a "driver busy" status. It would be much
easier if Apple would simply give us port management.
(stepping off the soapbox...)

Thanks to Leonard for another opportunity to vent my port management
frustrations... :-)

Jack Brindle
ham radio: wa4fib
internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Mon, 1 Jun 1992 20:13:03 GMT

.cc.umich.edu> [e-mail] writes:

       You may have noticed that MacLink comes with a special cable along
   with a "black box" which attaches to the cable for those "high speed transfers".
   That "black box" provides an external clock to the SCC, like the wires in
   the LocalTalk boxes.  that is the ONLY way to get above 57.6Kb with the Mac's
   current SCC & serial driver - external clocking!


LocalTalk does NOT use external clocking. The SCC can go at 240 kBPS
using async clocking (no external clock) or at 1 MBPS using external
clocking.

   >Can Apple come out with a update to the Comm Toolbox or a Snippet
   >so all the programmers out there can write a safe high-speed serial
   >app?
   >
       Apple needs to do some more work on interrupt handling when AppleTalk
   is in use first, then some work on making the serial driver a bit more robust
   and THEN maybe we could at least do 57.6Kb.

Uh... the driver already does 57.6 kbps supported... And Apple
HAS done a lot about the serial drivers and LocalTalk load -
you just have to pay for it (Q900/950 and IIfx have this fix,
it's in hardware)

The problem with localtalk is that the interrupt handling the
incoming character HAS TO KEEP ON READING until the block has
arrived; there's no time for interrupt-handling things at
localtalk speeds. So you stay with interrupts disabled for a
long time when using LocalTalk.

- --
h++ - new and improved !

A Bus Station is where buses stop. A Train Station is where
trains stop. On my desk, there is a Work Station.

+++++++++++++++++++++++++++

From: [e-mail] (Peter Creath)
Date: Sun, 31 May 92 22:53:04 CDT
Organization: Cube Technologies


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] writes:
>     Apple needs to do some more work on interrupt handling when AppleTalk
> is in use first, then some work on making the serial driver a bit more robust
> and THEN maybe we could at least do 57.6Kb.

ZTerm handles it just dandily.  My Telebit has no problem zooming
along at 57.6k.  I just want 115.2k so that when my WorldBlazer arrives
I can go at ITs top speed...

(not that I'm going to get throughput above 57.6k anyway, but it's
just a nice feeling)

- ----------------------------------------------------------------------------
Peter Creath                 "When I was a boy I was told that anybody could
[e-mail]   become president; I'm beginning to believe it."
                                                           -- Clarence Darrow

---------------------------

End of C.S.M.P. Digest
**********************